Summary

• Publish to VS Code Marketplace and Publish to Open VSX now run with continue-on-error: true.
• Create GitHub release runs as long as at least one registry accepted the publish (so the .vsix + SBOM still land somewhere a user can grab them).
• New trailing Registry publish status step re-asserts the job-level failure when either publish errored — so partial-success runs are still red in the run UI, in branch protection, and in any notification wiring.

Why

v1.0.2's publish run (26152644715) failed at Publish to Open VSX with an HTTP 405 — a transient Open VSX server-side hiccup (v1.0.1 shipped unchanged 14 h earlier through the same code path). Because the publish step is a run: script under bash -e, the job aborted at that line and Create GitHub release never ran. Net state for v1.0.2 was: ✓ VS Code Marketplace, ✗ Open VSX, ✗ GitHub Release. Recovery cost a fresh 1.0.x tag (v1.0.3 via PR #34).

After this change, that same incident would have left v1.0.2 on Marketplace and on GitHub Releases, with only the Open VSX gap to chase — no need to burn a new tag to recover the GH release.

Behaviour matrix

Rows 2 and 3 are the changed behaviour. Rows 1 and 4 are unchanged.

Why conclusion not outcome in the status gate

The status step uses steps.<publish>.conclusion == 'success' to decide whether to run, but steps.<publish>.outcome to decide whether to fail. That's deliberate:

• outcome is the raw step result (the actual exit-code success/failure).
• conclusion is the post-continue-on-error roll-up (always 'success' for any continue-on-error step that ran, 'skipped' for steps that didn't reach execution).

So:

• conclusion == 'success' filters out runs where lint/tests/audit failed upstream of publish — the status step stays quiet on those.
• outcome != 'success' correctly catches a real registry failure even though continue-on-error masked it from the job-level result.

Test plan

• YAML parses (python -c \"import yaml; yaml.safe_load(open('.github/workflows/publish.yml'))\").
• Reviewed expression semantics against GitHub Actions docs on steps.<id>.outcome vs .conclusion.
• Real-world validation comes on the next release — a successful publish (both registries green) exercises rows 1 of the matrix. The partial-failure rows can only be exercised by a registry returning an error, which is by definition out-of-band — no good way to test in advance short of pointing OVSX_PAT at a deliberately-bad endpoint.

Out of scope

• Backfilling the GitHub release for v1.0.2 (still cosmetically missing). v1.0.3 supersedes v1.0.2 on every channel; cheap to add later if you want strict per-tag parity.
• Automated re-publish-only mode for the failed-registry retry case. The current workflow does support workflow_dispatch with tag: input, and with this PR a manual re-dispatch on the same tag is safer (a duplicate Marketplace publish would now continue-on-error rather than abort the job).

🤖 Generated with Claude Code